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VOICE OVER IP SERVICE IMPLEMENTATION FOR PROVIDING 

MULTIMEDIA FEATURES 

Technical Field 

[0001] This invention relates to a technique for providing a Voice-Over Internet 
Protocol (VoIP) service implementation that affords a subscriber all of the features of an 
embedded traditional voice network while providing support for multimedia and Internet- 
based web applications. 

Background Art 

[0002] Traditionally, telephone subscribers have received Plain-Old Telephone 
Service (POTS) from a Public Switched Telephone Network (PSTN). In a conventional 
PSTN, the receipt of an incoming featured call (e.g., an 8XX, 900 or SDN call), at an 
ingress telephone switch of a toll network, such as the AT&T network triggers a query to 
a database, typically known as a Service Control Point (SCP) or a Network Control Point 
to obtain instructions for processing the call. Over time, and often at great expense, 
conventional toll networks have established a large embedded base of voice features for 
such featured calls, such as for example, time-of-day routing. 

[0003] Today, providers of telecommunications service have begun to migrate 
from traditional circuit-switched networks to packet-based networks that offer Voice over 
Internet Protocol (VoIP) telephony. However, in connection with such a migration, 
service providers do not want to forego the opportunity to provide their subscribers with 
conventional services traditionally available in the circuit-switched PSTN. 

[0004] Heretofore, a service provider migrating to a packet network architecture 
had to employ a call handling mechanism within the packet network itself to re-create the 
call features traditionally available in the circuit-switched PSTN. Adding such a call 
handling mechanism to a packet network to re-create the embedded features in the PSTN 
imposes a significant cost. United States Patent Application Serial No. 09/824,378, filed 
04/02/2001, entitled "Technique For Providing Intelligent Features For Calls In A 
Communications Network Independent Of Network Architecture" and assigned to 
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AT&T, (incorporated by reference herein) describes an approach for overcoming this 
problem by utilizing a common database in telecommunications network having both 
circuit-switched and packet-based call handling systems. The database contains a 
common set of call processing instructions accessible to both the circuit -switched and 
packet-based call handling systems thus avoiding the need to replicate features embedded 
in the circuit-switched components for use by the packet-based call handling mechanism. 

[0005] While the approach described in the aforementioned '378 application does 
resolve some of the difficulties associated with providing conventional calling features to 
VoIP calls, the approach does not address how to afford an IP endpoint the ability to 
implement a stateless or stateful multimedia application. The '378 application also does 
not address the need to provide local number portability, and dynamic addressing of 
network endpoints. 

[0006] Thus, there is a need for a technique for providing a Voice-Over Internet 
Protocol (VoIP) service implementation that overcomes the aforementioned 
disadvantages of the prior art. 

Brief Summary of the Invention 

[0007] Briefly, in accordance with a first aspect of the invention, there is provided 
a method for processing a call dialed to an IP endpoint in a communications network to 
afford the endpoint the ability to implement a multimedia application if desired. In 
accordance with the method, the call is received in the network server for processing. In 
practice, a voice (POTS) call originated at a traditional telephone is converted into a 
VoIP format and signaling information associated with the voice call is mapped into an 
appropriate format corresponding to the VoIP call. In response to the receipt of the call, a 
session is established with the IP endpoint by first resolving the address associated with 
the end point. In connection with the call, a determination is made whether the called 
endpoint IP end point desires a multimedia application, and if so, the desired multimedia 
application is desired. 

[0008] In accordance with another aspect of the invention, a method is provided 
for routing calls that originate either in a traditional circuit-switched environment, such as 
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a PSTN or in a packet-based network and are dialed to an endpoint such that a common 
local routing number database is employed for Local Number Portability queries. In 
accordance with the method, an incoming call is received at one of a voice and IP call 
servers, depending on whether the call is formatted as a traditional voice (POTS) call or 
has a VoIP format. In response to a call at one of the call servers, a query is launched to 
a common Local Number Portability (LNP) database serving both call servers. The LNP 
database responds with a local routing number returned to the requesting call server, 
which in turn routes the call to its intended destination. 

[0009] In accordance with yet another aspect of the invention, a method is 
provided for processing a call dialed to an IP endpoint in a communications network to 
afford dynamic addressing. In accordance with the method, the call is received in the 
network at a call server for processing. In response to the receipt of a call, the call server 
establishes a session with the IP endpoint by referencing the dialed end point through a 
Universal Resource Locator (URL) assigned to that end point. Using a URL in place of 
conventional IP address allows for dynamic address assignment, and allows for various 
call handling options when the end point is unavailable. 

Brief Description of the Drawings 

[0010] FIGURE 1 depicts a block schematic diagram of a network architecture in 
accordance with a preferred embodiment of the invention for providing VoIP service; and 
[001 1] FIGURE 2 depicts a illustrative call flow for the network of FIG. 1. 

Detailed Description 

[0012] FIGURE 1 shows a block schematic diagram of a network architecture 10 
for providing Voice over Internet Protocol (VoIP) services to both traditional voice 
endpoints (POTS terminals) as well as Internet Protocol (IP) endpoints. In the illustrated 
embodiment, the network 10 serves conventional (POTS) voice terminals 12 and 14 
through a PBX 16 and an End Office (EO) 18, respectively. (While FIG. 1 depicts a pair 
of voice terminals 12 and 14, the network 10 can readily serve a larger or smaller number 
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of such terminals without departing from the scope of the invention.) Both the PBX 14 
and the EO 16 have bearer connections to a Packet- Voice Gateway (PVG) 20 that 
converts Time-Division Multiplexed (TDM) calls originated at the voice terminals 12 and 
14 into an IP packet format for routing by a packet fabric 22 into an IP common back 
bone 24, typically via the Resource Reservation Protocol (RSVP). In this embodiment, 
the PVG 20 comprises a media gateway manufactured by Nortel Networks, Richardson, 
Texas, whereas the IP fabric comprises a Nortel Network's Passport 8600 Routing 
Switch. 

[0013] In connection with routing the call, the Call Server 26 as instructed by 
SCP 28 may need to provide some specialized functions. For example, the Media Server 
23 may need to collect digits, provide announcements, and/or perform speech 
recognition. To that end, the Call Server 26 instructs the PVG 20 to establish a 
temporary bearer path connection via the IP fabric 22 to a media server 23 that functions 
as an Intelligent Peripheral (IPe) to collect the required data and provide the requisite 
announcements and other services that may be required in connection with the call. 

[0014] A voice call server 26 has a signaling link to each of the PBX 16, the EO 
1 8 and the PVG 20 for providing the necessary signaling information to the PBX, the EO 
and PVG, respectively, to perform the required call set-up and call tear down functions. 
In this embodiment, the call server 26 comprises a Nortel Networks Succession Model 
CS 2000 call server that has a Primary Rate Interface (PRI) signaling link to the PBX 16, 
an Integrated Services User Part (ISUP) signaling link to the EO 18, and a H.248 protocol 
link to the PVG 20. No only does the call server 26 perform the signaling to effect call 
set-up and call tear-down, the call server also typically records events for downstream 
billing, as well as providing alarms and measurements for trouble shooting and 
maintenance. 

[0015] The voice call server 26 has a signaling link to a SCP 28 (i.e., a database) 
that contains call-processing instructions. The call processing instructions in the SCP 28 
provide the call server 26 with routing information for handling special-featured calls, 
such as those dialed to an 800, 888, 877, 866, 900, 700, or 500 exchange, as well as SDN 
calls. In practice, the call server 26 queries the SCP 28 using the Transaction Capabilities 
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Application Protocol (TCAP) routed via a SS7 link or an IP query over an IP network 
(we use TCAP over IP but it could be any suitable protocol such as SIP). 

[0016] As an example of the call processing instructions provided by the SCP 28, 
consider an incoming call dialed to an 8 YY number for which the called party has 
requested the time of day routing. Upon receipt of such a call in the network 1 0, the call 
server 26, when so notified of such a call from either the PBX 16 or the EO 18, will 
query the SCP 28 for routing instructions. Depending on the time of day, the SCP 28 will 
return different routing instructions corresponding to the desired routing by the called 
party. To populate the SCP 28 with the appropriate routing instructions to effectuate the 
desired call routing, the operator of the network 10 will typically make use of a Service 
Management System (SMS) 30. The SMS 30 receives customer input data regarding 
desired call treatment and converts that information into one or more appropriately 
formatted instructions for entry in the SCP 28. 

[0017] In addition to a link to the SCP 28, the call server 26 also has a signaling 
link to a second database 31, typically referred to as a Local Number Portability (LNP) 
database because it stores local routing numbers. Telephone subscribers in a given 
telephone exchange sometimes choose to switch their provider of local service, but yet 
elect to retain their original telephone numbers. To route a call to such subscribers that 
have elected to retain their original numbers, the current service provider will typically 
assign a location routing number (LRN) corresponding to the original telephone number 
elected by the subscriber. Prior to routing a call, the call server 26 queries the LNP 
database 3 1 for the location routing number, typically via a TCAP over IP query. While 
the network 10 of FIG. 1 depicts separate databases 28 and 31 for call routing instructions 
and local routing numbers, respectively, a single database, (i.e., the SCP itself) could 
contain both call routing instructions and location routing numbers. Thus, a single query 
to such a combined database would result in a return to the call server 26 of both routing 
instructions and a location routing number. 

[0018] In addition to serving the voice end points 12 and 14, the network 10 also 
serves one or more IP endpoints, illustratively exemplified by PC phones 32 and 34. The 
end points could take other forms, such as IP telephone sets, set top boxes or other wired 
or wireless devices that operate via an IP link. (While FIG. 1 illustrates only two IP end 
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points, the network 10 could easily support a larger or smaller number of such end points 
without departing from the scope of the invention.) In the illustrated embodiment, the 
network 10 serves the PC telephone 32 through an IP PBX 36 having a bearer path to an 
Edge Router 38, which in turn is linked to the common IP backbone 24. The PC 
telephone 34 is served via a Cable Modem (CM) comprising part of a Broadband 
Telephone Interface 42, typically coupled via Hybrid fiber coax connection to a Cable 
Modem Termination System (CMTS) 44 linked via a bearer path to the ER 38. The ER 
38 serves to route an incoming call to one of the PC phones 32 and 34 that originated 
from the other of the PC phones or from one of the voice terminals 12 and 14. In that 
regard the Call Server 26 may need to access a Domain Name Server (DNS) 46 for 
resolving address information for the call destination. Not only does the ER 38 route 
calls, the ER may also implement any desired Quality of Service (QoS) algorithms to 
assure a guaranteed level of service for telephony and multimedia applications. 

[0019] A Virtual Call Controller (VCC) 48, typically in the form of an IP 
Softswitch of a type available from one of several vendors of telecommunication 
equipment, has signaling links to each PC phones 32 and 34 and to the IP PBX 36. In 
practice, the VCC 48 includes a Session Initiation Protocol (SIP) proxy 50 that 
communicates signaling information to the PC phones 32 and 34, the IP PBX 36 and the 
ER 38 using the Session Initiation Protocol. The SIP proxy 50 also includes a 
Gatekeeper function that uses the H.323 protocol for communicating with the IP PBX 36 
and the H.248 protocol for communicating with the ER 38, although the SIP proxy could 
employ other protocols as well. By virtue of its signaling links to the PC phones 32 and 
34, the IP PBX 36 and the ER 38, the SIP proxy 50 provides the proxy function (i.e., the 
signaling information and address resolution) to control set-up and tear down of calls 
originating from, and terminating at the PC phones. Also, by controlling the ER 38, the 
SIP proxy server 50 assures that customers who require a guaranteed level of service 
receive such service. 

[0020] The VCC 48 has a signaling interface 52 through which the call controller 
launches a TCAPover IP query on a signaling link to the LNP database 3 1 for a location 
routing number. In addition, the signaling interface 52 allows the VCC 48 to launch 
TCAPover IP query to the SCP 28 to receive call-handling instructions. Like the 
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aforementioned U.S. Patent Application Serial No. 09/824,378 (incorporated by reference 
herein), the network 10 employs a common SCP 28 that is accessible to both the VCC 48 
and the voice call server 26. In this way, a customer can have same routing logic 
controlling the routing of voice calls to and from the voice terminals, such as voice 
terminals 12 and 14, and IP calls to and from the IP endpoints, such as PC phones 32 and 
34. Although FIG. 1 depicts the SCP 28 as a single database, in practice, the call server 
26 and VCC 48 could access separate SCPs, each containing the identical routing 
information. 

[0021] In addition to having a signaling link to the SCP 28 and the LNP database 
3 1, the signaling interface 52 of the VCC 48 enjoys a direct signaling link to the call 
server 26 to allow the exchange of signaling information via the SIP-T or BICC over IP 
protocol (BICC and TCAP can also work over the conventional SS7 signaling network.). 
In this way, the VCC 48 may effectively interwork with the voice call server 26 for non- 
featured calls directed to one of the voice terminals 12 and 14 from one of the IP 
endpoints. 

[0022] Along with the SIP proxy 50 and the signaling interface 52, the VCC 48 
further includes an IP applications controller 54 for controlling IP and/or multimedia 
applications requested by one of the IP endpoints, such as one of PC phones 32 and 42. 
To that end, the IP applications controller 54 of the VCC 48 has a signaling link to a IP 
services database 56 so that the IP applications controller can launch a query via one of 
several known protocols, such as SIP, or Java Advanced Integrated Network (JAIN), or 
Lightweight Data Access Protocol (LDAP), to gain the requisite information needed to 
control the desired IP application. In some instances, the desired application is a 
"stateful" application that requires certain record keeping and other management 
activities so that the IP controller 54 remains involved during the application. Other 
desired applications may be so-called "stateless" applications where no record keeping or 
management is required in which case, the IP controller simply initiates the desired 
application and thereafter drops off so that the end points (i.e., the PC phones 32 and 34) 
will communicate directly, via the Internet or such other connection and implement any 
desired features. 
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[0023] FIGURE 2 shows an illustrative call flow in the network 10 of FIG. 1 for a 
voice call launched from the voice terminal 12 to a call center served by the IP PBX 36, 
The call flow proceeds as 

1 . The caller (represented by voice terminal 12) dials a 10-digit number of the call center. 

2. The PBX 16 collects the dialed digits, analyzes them and determines that the information 
concerning the call should be routed to the call server 26. The PBX 16 sends information in 
a Q.93 1 setup message that includes the called number, the circuit the PBX will use for the 
voice path and optionally the calling number of the caller. 

3. The voice call server 26 receives the setup message, analyzes it, and formulates a query 
(i.e., a TCAP query) that contains the dialed number, the call reference number, and other 
information. The voice call server launches the query to the SCP 28 for further processing. 

4. The SCP 28 receives the query, and processes it according to information and logic input 
stored in the SCP from the customer. The SCP 28 forms a TCAP response that is sent to 
the voice call server 26. 

5. The voice call server 26 receives the TCAP response, and in turn, sends a Q.93 1 
proceeding message to the PBX 16. Additionally, the voice server call server 26 sends a 
H.248 protocol create connection message to the PVG 20 which enables a conversion of 
the digital circuit (from the PBX 16) to an IP packet port. 

6. The PVG 20 sends an acknowledgement message to the voice call server 26 that the 
"connection" has been made. 

7. The voice call server 26 formulates a BICC Initial Address Message (BICC IAM) that 
contains the IP address of the PVG 20, the routing number, and other information (e.g. 
calling number) that is sent to the VCC 48. Note that in cases where the number has been 
ported, the voice call server 26 must query the LNP database 31 to determine the routing 
number. In this case the LRN response points to VCC 48, but in general it could indicate 
another Call Server, or a circuit switch, or even another network. This is a TCAP query 
that is similar to the SCP query in steps 3 and 4. 

8. The VCC 48 receives the BICC IAM and formulates a DNS query containing the routing 
number that is sent to the DNS server 46. The DNS 46 receives the query and translates 
the routing number into an IP address of the call center PC phone 32. The DNS 46 returns 
the IP number to the VCC 48. (Of course, in the case of a circuit endpoint or another 
circuit or IP network, the DNS will return the IP address of the gateway to that network.) 

9. The VCC 48 formulates and sends a SIP Invite message to the Call Center PC phone 32. 

10. The Call center PC phone returns a SIP 183 message that contains the IP address on 
which the PC phone will receive the bearer stream, typically in a Real Time Transport 
(RTP) protocol stream, and alerts the called party that a call is incoming. 

11. The VCC 48 receives the 183 message and formulates a BICC Address Complete 
Message (BICC ACM), which contains the IP address that the PC phone 32 will receive 
the incoming RTP stream. 

12. The voice call server 26 receives the BICC ACM message and sends an alerting message 
to the PBX 16 

13. The PBX 16 plays ringing to the calling party. 
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14. After receiving the 183 message, the VCC 48 sends a gate allocate message to the ER 38 
to reserve a gate for the RTP stream from the PC phone 32. The ER 38 acknowledges the 
message. 

15. The voice call server 26 sends a modify connection to the PVG 20 to open the gate so 
packets can flow via a voice circuit to the PBX 16. 

16. The called party answers the PC phone 32 and sends a SIP 200 OK message to the VCC 
48. 

17. The VCC sends an H.248 message to the ER 38 to open the gate. The ER 38 router 
acknowledges the message. 

18. The VCC 48 sends a BICC Answer message to the voice call server 26. 

19. The PBX 16 receives the Q.93 1 connect message and cuts through the call to the calling 
party (voice terminal 12). The PBX 16 sends a connect acknowledge message to the voice 
call server 26 

20. The talking path is established. 

2 1 . When the subscriber at the PC phone 32 hangs up, the phone sends a SIP BYE message. 
The VCC 48 acknowledges this message with a 200 OK and the PC phone 32 
acknowledges this message with and ACK. 

22. The VCC 48 sends a BICC Release message to the voice call server 26. The voice call 
server 26 sends a release message to the PVG 20 

23. The VCC 48 sends a H.248 release message to the ER 38. 

24. The voice call server 26 sends a Q.931 release message to the PBX 16, which, in turn 
sends a Q.93 1 release complete message back to the VCC 26. 

25. The PBX 16 disconnects voice terminal 12. 

[0025] The foregoing describes a technique for providing a Voice-Over Internet 
Protocol (VoIP) service implementation that affords a subscriber all of the features of an 
embedded traditional voice network while providing support for multimedia and Internet- 
based web applications. 

[0026] The above-described embodiments merely illustrate the principles of the 
invention. Those skilled in the art may make various modifications and changes that will 
embody the principles of the invention and fall within the spirit and scope thereof. 



